This looks like it is only useful for profiler_hook loggers that don't distinguish between CPU and GPU timing, i.e. only the summary and nested_summary loggers, right? I'm not sure yet if this is enough of a reason to add a separate logger event for it. If we use device timers, we get correct device timings on the high level, if we use host timers, we get correct host timings, if we want to get some mixed information, you get more reliable results from a purpose-built tracing tool like NSight Systems or rocProfiler.

Additionally, it seems like this would add some additional noise to the profiler output for executors where synchronize is a no-op.

I am not big fan to provide this when we can use the vendor profiler directly.
It should not give misleading information if we provide it.
On later point, we may have benchmark with two loggers for gpu and cpu and it will help to know cpu time is used in syncrhonization not actual function although it needs different host allocator from #1897

Let me be a bit more precise: The noise is the biggest issue to me. If the executor doesn't do anything when synchronizing, it also shouldn't show up in the output.

Looking at where we actually call synchronize explicitly in Ginkgo, this seems all related to distributed use cases or copies (there are a few other places, but I think they are unnecessary). For that purpose, maybe it makes sense for us to spend some more time thinking of asynchronicity and futures, since that's essentially what we need here to avoid the duplicate synchronization. With explicit device-related futures, we can provide a function that waits for multiple streams (and if they are the same, remove any duplicate waits), which would then allow us to add asynchronous copy functionality to all executors. But also to be clear about terminology: I don't mean using multiple threads, I mean using a single thread to poll multiple futures. If we get this right, we can also cleanly extend it to a multi-stream setup, which would allow us even more overlapping of operations.

Asynchronous is different topic.
We call that, so we should have it in log. if it is a noise because of no-op, we should avoid no-op call not avoid logging no-op.
If you mean the duplicated wait from copy itself and the explicit wait in gko copy,
We can not avoid duplicate synchronous, because the documentation only mention it might sync so it might not if the memory is pageable. Also, we can not force user to use cudaMallocHost to allow actual async copy here.
If you mean the duplicated wait from many copies, it is one slow down factor when we call several copy at the same time, which should be avoided.
However, you still need to call wait when you try to get the value which is indeed the updated value.